Issue number: #1668

Summary

By default, Metrics shares data across instances. This allows customers to instantiate Metrics in multiple places throughout their code - be a separate file, a middleware, or an abstraction.

However, there are three cases where this is a disadvantage:

• You want to create the same metrics for different applications
• You use a metric dimension to distinguish a metric per tenant (EMF mandates the same dimension for all metrics in a given JSON blob).

Changes

Please provide a summary of what's being changed

This PR introduces a new class: EphemeralMetrics. This makes an explicit contract that instances of EphemeralMetrics will not share data sets (metrics, dimensions, metadata).

Quick summary on differences:

User experience

Please share what the user experience looks like before and after this change

from aws_lambda_powertools.metrics import EphemeralMetrics
from aws_lambda_powertools.metrics import MetricUnit
from aws_lambda_powertools.utilities.typing import LambdaContext

metrics = EphemeralMetrics()

@metrics.log_metrics
def lambda_handler(event: dict, context: LambdaContext):
    metrics.add_metric(name="SuccessfulBooking", unit=MetricUnit.Count, value=1)

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics
• Explicit test for nested log_metrics use case

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.